Databases are susceptible to corruption/inconsistencies while they are in use. Inconsistencies can be introduced by operator error, hardware failure, a problem with controller firmware, etc.
A database may include file system metadata, which essentially consists of a hierarchical arrangement of directories and files. When corruption occurs or is suspected, an error checking and correction process can be run to check the validity of entries in the database and find any errors. One such process is commonly known and referred to as “FSCK” (file system consistency check). A tool commonly used to identify and fix corruptions of NTFS (New Technology File Systems) is referred to as “chkdsk.”
A problem with processes such as FSCK is that they can take a relatively long time to run. For example, FSCK can take several tens of hours to run, depending on the size of the database. While FSCK is run, the database may be taken offline, which makes it inaccessible to other system components and processes that rely on it.
If FSCK is run while the database is online, then an exclusive (write) lock on the database is acquired in order to prevent the database from being changed while the check is being performed. For a database such as a directory inode, which may have many thousands if not millions of entries, the exclusive lock prevents other processes from performing even read operations on the directory for several minutes. While this may seem like a relatively short amount of time, it is not in practice as several minutes of delay can inconvenience large numbers of users, especially in global file systems such as storage area networks (SANs) and cluster file systems.